Computers systems typically have operating systems that access media devices, such as disk drives, through low level device drivers. Applications generally execute above the operating system and pass file system calls through the operating system to store or access data on media devices. The file system calls are typically handled at a low level by the device driver associated with the particular media device.
There can be situations when it is desirable for an application to perform a direct media I/O to a media device. In this case, the access would not pass through the file system. However, this direct I/O can be dangerous in that there must be an assurance that the structure of data on the media device is known. Otherwise, active data could be improperly handled or overwritten. One means for obtaining this assurance is to obtain a lock on the media device by which only the locking application has access to the media device. However, some media devices, such as boot volumes in WINDOWS NT, are non-lockable. In other words, there is no defined interface that allows an application to gain exclusive access to the media device.
In conventional systems, if the operating system is not running on a media device (e.g., a volume of a disk drive), the system will often allow a user program or application to obtain exclusive access to the media device. If a media device is deemed non-lockable, an application could always boot from another operating system with the desired media device attached as a "lockable" device and perform the desired action with the media device under an exclusive lock. However, there are no conventional options for providing "error free" direct I/O to a media device, such as a volume of a fixed disk, while an operating system is up and running and has deemed the media device non-lockable.
Further, it can be desirable to "flush" or "clean" file system residue from a media device, such as a disk volume, thus making it impossible for any data to be recovered from what was once a deleted file on the file system. In general, file system residue includes all aspects of deleted files that remain on the media device. For example, freed data on a volume of a disk drive will reside in many places on the format of the volume. Inactive data can reside in any freed allocations on the disk and also in the descriptors (attributes of the data) that house the name of old files along with pointers to where the old file data once resided. Despite the desirability of flushing all such file system residue, conventional flushing products only operate to flush the free allocations on the file system. This does not remove all of the file system residue from a deleted file. Rather, it only handles data that is in an unallocated state on the media device.